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1.0 INTRODUCTION 

This is the Informatics Inc interim report on the Advanced Naval Tactical Command 
and Control Study (ANTACCS) Phase II work under Contract Nonr 4388(00). The work is 
being conducted under the direction of the ONR Advanced Warfare Systems Division. 
Informatics Inc. delivered four volumns of the ANTACCS Phase I report and the material 
presented herein is a follow-on of the Phase I work and concentrates on three specific study 
tasks . 

The Development of the Scope and Operating Concept for a Naval 
Tactical Command and Control System for the 1970-80 period. 

The Development of a Description of the Command and Control Sub- 
system for a CVA for the 1970-80 period . 

The Development of a concept for a data system hardware and software 
family which might be utilized to fulfill the 1970-80 system requirements. 

All of the study tasks have been approached from the fundamental point of view 
that a major objective of the total ANTACCS effort is to provide assistance to Naval system 
planners who are responsible for future command and control system development and imple- 
mentation management. The study results, therefore, are not merely stated and described as 
products, but rather, ore described in a manner which shows the methodology or logical ap- 
proach used in developing the product along with the product description . This approach 
description allows system planners to test our work products by several mecns. First, the 
methodology used in arriving at problem solutions can be evaluated with respect to solving 
Navy problems, second, the input information and assumptions used may be analyzed for 
completeness or omissions and last, the product can be verified or altered by planners using 
more complete or more current input information and assumptions and reworking the problem 
using the analysis methodology. 

This problem approach is not foolproof, however, because techniques and metho- 
dology for informations systems analysis are still in infancy and may well not approach wide 
acceptance for many years. 
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Our objective in the methodology demonstration is to use the best problem solution 
approaches known to us today and update these with our recent experiences and judgement. 

The study tasks reported herein are presented at the current stage of completion. 

As an aid in following our work Figure 1 shows the study tasks in ANTACCS Phase 11 . 

2 

Those marked ii are the responsibility of informatics Inc., those marked EMC are the 

responsibility of Electronic Management Computerology Corporation. Those marked as 
mixed are the responsibility of both companies. The study tasks which are the responsibility 
of Hobbs Associates are not shown on the figure. 

Current plans and study emphasis indicate that the scope and operating concept 
study will be completed in January 1966. The results of this task are pivotal for studying 
future Naval tactical command and control systems, whether platform based (CVA), operations 

based (Anti Submarine Warfare), or command level based (CTF). Informatics, Inc. and 

2 
EMC are both working on this task. Section 2 describes the Informatics Inc work to date 

on the scope and operating concept task. 

Section 3 describes the Informatics Inc. progress to date on the CVA System 
Description Task. This progress is primarily based on our study visit to the U.S.S. America. 

Section 4 describes a preliminary concept for a data system hardware and software 
family and suggestsa new form of system development and implementation which may be 
possible using this approach. 

Section 5 presents the objectives and plan for the remainder of Phase II. 

Figure 2 shows the ii tasks and the man months expended against these tasks 
through September 1965. 
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2.0 SCOPE AND OPERATING CONCEPT TASK 

2.1 SCOPE METHODOLOGY 

This task has the objective of laying the groundwork for all of the ANTACCS 
Phase II tasks and for other studies in Naval tactical command and control . The scope 
and the bounds of the problems under consideration should be established in detail and 
understood at the completion of this task. The inputs to the task are the ANTACCS 
Phase I report, current tactical operations, predicted tactical operations, and Navy 
Guidance. The use of each of these inputs in the analysis is described next. 

Current tactical operations inputs are required to provide team orientation 
into the operations of Naval tactical forces. This orientation is for two purposes: to 
become familiar with the operational divisions and sections on the various Naval 
tactical units and to ascertain the areas which must be analyzed in detail during the 
study . 

Other types of information which may aid in understanding current tactical 
operations are operations orders, plans, and scenarios which may be available In 
OPNAV from past operations. 

The next Information Input is expected tactical operations. The primary 
sources of information are OPNAV, OEG and other Naval organizations which develop 
future doctrine, types of forces, and other tactical engagement necessities. The study 
team cannot hope to develop future tactical operations doctrine but merely to use expert 
opinion from the previously mentioned Naval offices as an information base in analyzing 
automation/mechanization potentials to predicated tasks and functions required in these 
tactical operations. The Phase I report also provides Inputs to the detailing of scope and 
operating concept because It contains a collection of requirements information for various 
nodes of Naval tactical organizations. 
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In using Naval guidance Inputs, emphasis is focused on bringing together 
information from ONR, OPNAV, BUSHIPS, OEG, NAVCOSSACT, Fleet Programming 
Centers, and Operational Fleet Personnel to insure that the study team is working against 
realistic expected command support requirements and environment. 

The general procedure for defining scope using these various inputs is shov/n 
in Figure 3. The first step, defining subject areas, requires an understanding of the 
general type of system under study. As in all definition problems criteria are required 
for selecting among alternates. Development of these criteria is shown as the next step. 
Collection of information which relates to the subject areas is shown to be dependent on 
the sub'ect areas selected. Next the collected information is filtered using the various 
criteria and a preliminary scope definition is formed. Iterations through this general 
procedure are shown to allow refinement of the definition against overall scope definition 
criteria. 



2.2 



SCOPE SUBJECT AREAS 



The subject areas for defining the scope are: 

1 . Levels of command and staff to be supported, including a 

2 

method for defining a level of command. (EMC ) 

2. A delineation, for each level of command, of the range of 

operational tasks to be supported. This may take the form 

2 

of several matrices as follows: (EMC ) 
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3. A description of expected tactical organizations, in- 
cluding a discussion of how various tactical organizations 

2 

might be formed to perform operations or missions. (EMC ) 

4. A description of the platforms which will be used includ- 
ing life expections for each unit type. (li) 

5. A matrix which relates platforms and levels of command, (ii) 

6. A general description of the type of information which will 
be used and exchanged regardless of degree of mechanization 
of particular portions of command or communications, (ii) 

7. A discussion of the constraints on tactical systems caused by 
the National Organization of Vertical Systems, i.e., 
logistics, intelligence, communications, weather, etc. (ii) 

8. A description of the expected reporting requirements of 
tactical commanders to Naval and National Command 
levels, (ii) 

9. A description of Information handling and communications 
systems which may be present In the environment with any 
tactical C&C system with particular emphasis on time phasing 
of operational usefulness, information exchange among systems, 
and information processing functions of the various systems. 

(i!) 

10. A description of the Information precessing functions which 
support the operational tasks, (ii) 

2 

NOTE: The EMC or ii at the end of the subparagraph Indicate the contractor 

who has re^onsibility for the subparagraph or paragraph. 

Figure 4 shows the interrelationships of these ten subject areas. It also 
shows how these subjects contribute to the scope definition which consists of operational 
scope. Informational scope and environmental scope. 
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The Operational Scope Is a statement of the operational tasks of each command 
level in the expected tactical organizations. Each command level is also keyed to the 
type of ship where the commander may be embarked. This scope statement is dependent 
upon definitions of tactical organizations, levels of command, platforms, and opisrational 
tasks (delineation of responsibilities) of commanders. This scope statement is time 
dependent, since platforms and tactical organizations will change with time. The 
operational tasks in specific detail are also time dependent. However, the general 
task requirements to prepare operations plans, to organize resources, and to direct and/ 
or control operations will remain constaint over time. 

The Informational Scope is dependent upon the operational scope. It consists 
of a description of the information types, flow, and processing functions. It is particularly 
important to state this information for each level of command (node), and for the total 
command organization. 

The Environment Scope is a two level statement. Each information handling 
system in the environment bounded by the Operational Scope should be dexribed by 
the information processing functions supported, time of system operational capability, 
and the system elements (and location). 

The second part of the enviornment scope definition Is developed by matching 
these descriptions with the informational scope definitions. 

In summary. Informatics Inc. Is responsible for the following scope stud/ 
areas: 

Describing Platform types over the Time Period of operational Usefulness 

Describing the relationships between Platform and Levels of Command 

Describing the Information Used and Exchanged 

Describing National Vertical Systems which may effect Tactical 
C&C Systems 

Describing Expected Reporting Requirements to High Echelons 

Describing the information handling systems which may be present In 
the operational environment 

Describing the Information processing functions which support the operational tasks. 
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The remainder of the section describes our progress on these study areas. 

2.3 SCOPE CRITERIA 

A number of criteria have been developed in order to analyze the subject 
area members. These criteria are presented below by scope subject area. 

Platforms 



1 . Does the platform participate in a tactical operation? 

and 

2. Is the platform organic to a task organization? 
and 

3. Is the platform a combatant unit or command unit? 
and 

4. Will the platform be operational in 1970-80? 

Platforms Vs Level of Command 



1 . Is the platform designed to support a task element or 

unit commander? 
or 

2. Is the platform designed to support a task group or force 

commander? 

Information Types Used and Exchanged 

1 , Is the information command information (orders and reports)? 

or 

2. Does the information support tactical operations planning, 

directing, or controlling? (own forces information, enemy 
forces informations, environmental information)? 
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National Vertical Systems 

1 . Does the National Vertical System provide material 
support to tactical units? 

or 

2. Does the National Vertical System provide information in 

support of tactical operations (intelligence, environmental)? 
or 

3. Does the National Vertical System provide facilities to 

tactical units (communications terminals)? 
or 

4. Does the National Vertical System prescribe procedures 

to tactical commanders? (Emission control, encryption, 
frequency allocations) 

Reporting Requirements 

1. Is the report based on tactical operations? 

or 

2. Does the report contain intelligence or weather information? 

or 

3. Does the report contain own force status or position 

information? 

Other Systems 

1 . Is the system organic to a tactical unit or tactical organization? 

and 

2, Does the system acquire^ process^ or disseminate tactical command 

or command support information? 
and 
3.;.Will the system be operational in the 1970-80 period? 
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Information Processing Functions 

1 . Does the function support command decisions? (plan approval, 

engagement, weapons usage, etc.) 
or 

2. Does the function support information decisions? (Message 

routing, track correlation, track identification, etc.) 
or 

3. Does the function provide own resource information? 

or 

4. Does the function provide environmental Information? 

or 

5. Does the function provide Intelligence information? 
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2.4 INFORMATION ON SUBJECT AREAS 

Informatics Inc. has made a number of visits to Naval offices in order to 
obtain Input Information to the subject areas. A number of further visits and document 
reviews are required to complete the data gathering. Our progress In each of the 
subject areas Is described next. 

Platform Types Over Time Period Operational Usefulness 

Informatics Inc. Is currently using the information provided In the ANTACCS 
phase I report, Volumn II. Details will be expanded and verified during the next 
period. 

Relationship Between Platforms and Levels of Command 

' This task Is dependent on the Information currently being supplied by 

2 

ECM . The study task will be accomplished in the next period. 

Information Handling System in the Envrionment 



The systems which have been partially described to date in Phase 1 are: 

NTDS, ATDS, MTDS, CAPE, SINEWS, SHIELD, ASWEPS, TFDS, TRANSIT, 
SINS, SOSUS, ASCAC AND FFDS. 

These descriptions all require more detail concerning operational concepts, 
type and formats of data, and time of operation usefulness. 

lOIS and A-NEW have been described in Phase II to date. ADSAF, ATACS, 
and Tl PI will be described during the next period. 

The interface or integration of these systems and an Advanced Naval 
Tactical command and control system will be established during the next period using 
the following definitions; 
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1 . Integration - This means that the system is assimilated by the 
C&.C system. All of the hardware, software, and procedures 
required are merged and the other system looses its identity. 

2. Electrical Interface - This means that the system and the C&C 
system are electrically connected for the transfer of control 
signals, information, etc. 

3. Information Interface - This means that the system and the C&C 
system are related through the transfer of information from one 
system to another using format rules, encoding standards, etc. 

4. Procedural Integration - This means that systems are integrated 
through human facilities, i.e., procedures are established so 
that people can perform tasks using both systems to support them. 
This usually requires the person to change the format, encoding, 
or the form of the information which is passed from one system 

to another. 

5. No relationship between the systems because there are no common 
functions or information. 

The five states of relationship are dependent upon the degree of similarity 
of the functions and information which the various systems support or work against, 
and the time phasing of the operational usefulness. 

National Vertical Systems 

Figure 5 shows our impression of the general relationships among systems 
which serve The National Military Command, The Service Department^ National 
Vertical Systems, and Tactical Forces. The four National Vertical Systems identified 
are: 

Jntelligence 
Weather 
Logistics 
Communications 



Page 2-12 



Tactical Command & Control Systems, Relationships, Support 

Figure 5 
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The principal characteristic of these national systems is that they can be 
divided into two general groups. 

Support Systems 
Information Systems 

The support systems, communications and logistics, provide services or 
resources to command activities. The information systems, intelligence and weather, 
provide information for use of command activities. 

At the present time the information systems can be classified as manual or 
semi-automatic systems. There is tremendous effort being expended to automate them. 

Informatics Inc. has obtained preliminary information on the Joint 
Meteorological Satellite Program and on the U. S. Naval Weather Service. It 
indicates that tactical forces of the 1970-80 will receive two principal types of 
weather information from non-organic systems. Analog or video imagery data and 
processed digital data will be available from burst type readout and teletype readout, 
along with general purpose broadcast. Rates, formats, specific contents, etc., will 
be published in reports by the Meteorological Offices in early 1966. Informatics Inc. 
will obtain this information and integrate It into the scope definition as appropriate. 

An important aspect of the logistic support systems is that it must be 
supported by an information system. A number of large systems currently exist to 
handle some of these information support requirements. Some information is available 
on the logistics system as well as on the communication and intelligence systems. 
Informatics Inc. will obtain this information and consider the impact which the 
National Vertical Systems may have on tactical C&C systems. The following questions 
will be used in this consideration. 

What constraints are imposed upon the tactical force information 
system by all vertical systems? 

How are the tactical C&C systems to be interfaced (see interfaced 
definitions above) with the vertical systems? 
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What are the message formats for each system? How do they compare 
with each other? What security level will be required? At what 
frequency will the message be sent or received? 

What are the operational conflicts between the various vertical 
systems and command and control ? 

What informational conflicts will arise as a result of the Interface 
of tactical command and control with National Vertical Systems? 

Who will have the authority to resolve any and all conflicts 
arising from the interfacing or integration of tactical command 
and control and National Vertical Systems? 

Who will establish the requirements for the vertical systems? 

What will the conditions under which the vertical systems will 
operate Independently and/or interface with tactical command 
and control ? 

Does the National Vertical System have a similar function 
(higher level) to the department or staff function of the 
tactical unit or command? 

If functional duplications exist and conflict, how will these 
conflicts be resolved - by whom? 

Does the National Vertical System work against Inputs from 
tactical forces? 

Does the National Vertical System provide Information to 
tactical units or command? If so, what type, etc.? 

Expected Reporting Requirements to Higher Echelons 



The areas of Investigation for the description of the expected report 
requirements to Naval and National command levels are: 



Page 2-15 



What type of operations and status reports are required in a 
normal environment? 

What type of reports will be required in an emergency environment? 

What will be the format requirements of each type of report? 

What will be the communication and security requirements of each 
type of report? 

Which command levels are responsible for the various reports in 
the normal condition? 

How will the command level reporting requirements change under 
actual engagements or emergency condition? 

What will the frequence of reporting requirements under normal 
and emergency conditions? 

Does the reporting requirement necessitate that new reporting by 
units or commands in addition to the present reporting? 

Figure 5 also indicates the general nature of the tactical force relationship 
to National Military Command, Naval Departmental and Type Command and National 
Vertical Systems Areas. It is readily apparent frorn this diagram that a tactical force 
will have information interfaces with all of the above named higher echelons. 

A very preliminary list of reports which may be required by the force 
command to one or more of these higher echelons is: 

Casualty 

Deployment and Movement 

Strike Related 

Situation 

Reconnaissance 
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CHOP 

Weapons Status 

Replenishment 

Acknowledgement of Orders 

Local Weather 

Engagement -^ 

Readiness 

Emission and ECM 

Interdiction Operations 

Individual Tactical Units may also be required to report to higher 
echelons beyond the task command using a number of the above named reports. 

Informatics inc. will be gathering more information on this subject and 
reportkjg it during the next period. 



Information Used and Exchanged 

This study area is currently underway. 

The primary sources for the development of this item are expected reporting 
requirements, operational tasks for each level of command, and information processing 
functions. As these items become final a general description of the type of information 
will be used and exchanged will be developed. The following set of questions have 
been established as guidelines in developing the description. 

What types of information will be exchanged? 

What are the level of command which exchange the various 
types of information? 
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What is the context of the information to be eKchanged by 
each level? 

What is the order of priority of the information to be exchanged? 

What will be the frequency of the information to be exchanged? 

What is the distribution of the information? 

Are the requirements for redundancy of information exchanged or used? 

How will the receiver use the information? 

What are the requirements for using the information exchanged 
by the various levels? 

Under what conditions will the information be exchanged and used? 

What will be the mode of exchange? 

What levels of security will the information have? 

Is the information related to an identifiable source as a tactical 
unit or tactical command function? 

Can the information be classified as command data? 

Can the information be classified as tactical data information support 
to the tactical unit department, tactical command staff, or commander? 

Information Processing Function s 

This task activity will be developed in concert with the EMC and the 
other Informatics Inc. scope items. 
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3.0 CVA SYSTEM DESCRIPTION 

3.1 PURPOSE 

The purpose of this work is to describe the data system which will support the 
CVA commander and the embarked Commander Task Group or Force. This system descrip- 
tion will cover the operational tasks to be supported, the technical functions and the 
data processing operations required. The description will be developed from the point 
of view that present hardware and software systems aboard the CVA will be the starting 
point for evolving to the advanced hardware/software concept described in section 4. 

3.2 PROGRESS 

The principal effort to date on this task has been the study visit to the operating 
CVA. The majority of the work will be completed after scope and operating concept 
definition has been established since the CVA system is a subset of the total Naval Tactical 
C&C system. 

The CVA visit was planned to fulfill the following objectives: 

To clarify our understanding of command procedures and 
activities on a CVA. 

To observe and summarize the type of information processing 
accomplished by staff and operating sections in supporting 
commanders during operations. 

To gain a first hand overview of the layout and relationships 
among the CIC, TAC PLOT, FLAG PLOT, AIR OPS., Bridges 
and other operating areas on the CVA. 

To isolate tasks, functions, etc. which may require future 
data system assistance. 

To obtain an appreciation of the commonality or diversity of 
information processing and historical information banks which 
are utilized by operating personnel. 

The team was able to meet each of these objectives for the following type of 
exercise operations: 
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1 . General Air Operations of Launch and Recovery both 
day and night 

2. Air Defense Exercise when under attack by aircraft 

3. Air Defense Exercise when under attack by aircraft 
using passive and active ECM. 

Briefings on the functions performed and observations of operations were made 
in the following spaces: 

Flag Bridge 

Flag Display and Decision 

Flag War Room 

Bridge 

Navigation 

Meteorology 

Communications Operations 

Combat Information Center 

Weapons Control 

Intercept Control 

ECM 

Surface Control 

Carrier Air Traffic Control Center 
Sonar Room 
Primary Flight Control 
Flight Deck Control 
Hanger Deck Control 
Engineering Control 
Damage Control Center 
Integrated Operational Intelligence Center 
Ready Room 

Supply Data Processing Center 
Computer Room for CIC 
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In addition to these observations, Admiral Cobb, Command Carrier Division 
Two and CTG for this exercise held a staff and study team meeting on 4 September. A 
number of general observations and questions were discussed at this meeting. The new 
FLAG Display and Decision (D&D) space on this ship which replaces FLAG PLOT was 
discussed in detail. The space is located below deck and is well located with respect 
to related ship spaces. Admiral Cobb and his staff indicated that this new area is 
being tested to ascertain whether it is superior to previous FLAG PLOT locations. Early 
indications are that the area appears better equipped to support the FL^G than previous 
areas. A further observation by the Admiral was that future FLAG officers may not 
expect a portable D&D but may move to the ships which have these facilities. In addi- 
tion, members of the FL\G staff briefed the team on individual responsibilities during 
the week. The team also received briefings on various exercises being conducted and 
purposes of the exercises. 

Figure 6 is an illustration of the command, staff and operations activities 
which were observed during the CVA visit. This diagram supports the generalization 
that a tactical C&C system must support two types of commanders. The tactical unit 
commander who works through and is supported by departmental heads as shown on the 
bottom of the figure, and the task commander who works through and is supported by 
a classical type military staff. The task command support functions are shown in the 
circle. 

In the command environment of a CVA there are two types of command infor- 
mation structure: 

] . The task directed command information structure of the 
CTF or CTG for tactical operations. 

2. The ship directed command information structure for the 
unit commander for the ship operations. 

In the task directed command information structure, the plans officer, the 
staff operations- officer and the specified operations officer (Air Operations, ECM, 
Strike Weapons, ASW, Intelligence, Surface Operations, and ASW) work closely 
with the operations officers of the ship to develop the plans for the tactical operation 
under command of the task commander. 



Figure 6 
Higher Command 
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The ship directed command information structure is focused on carrying out 
the operations order on a daily basis. The instrument used is the operation plan of the 
day. 

The operations plan of the day is issued by the executive officer, it is his 
interpretation of the operations orders for the CVA including the Air Wing. It states 
the guide lines that the department heads are to use in developing (planning) the 
activities for the department on a daily basis. The department head must interpret 
the guide lines within the frame of the job to be done, the resources and personnel 
required, the time to accomplish the job, and his authority and responsibility. Any 
deviation from or difficulties involved in the execution of the goals stated in the opera- 
tions plan of the day must be reported to the executive officer for resolution or redirection. 

With the department plan firmly established, the department head must 
organize, direct and control his personnel and resources so to accomplish each task in 
the time required. It is his responsibility to insure that the tasks are properly ordered 
so that his personnel and resources are neither strained nor slack as to be ineffective or 
non-responsive to change in direction. Through his subordinate officers the execution 
of his plan is directed and controlled. 

The department head will personally direct the major task and he will receive 
reports on the progress, possible and actual probelms encountered and recommendations 
on the other tasks from his officers. With this information, the department head will 
resolve any problems that may arise which fall within his area of responsibility and 
authority. In turn, he will report on progress, the possible or actual problems encountered, 
the condition of his men and resources, and the recommendation in carrying out the 
operations plan of the day to the executive officer. 
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3.3 . ANALYSIS GUIDELINES 

Some analysis guidelines to be used in developing the system for mechanizing or 
automating functions or function linkages on the CYA are listed below: 

Does the data input, processing, etc., exceed human capacity to 
handle without extensive queueing, etc . ? 

Can the function processing be logically expressed? 

Is the function characterized by large data base entry and lookup 
(IS&R) processes? 

Is summary data or information required rather than all available 
information? 

Does non-timeliness of function output or linkage data cause a delay in 
operations or other functions which may delay availability of informa- 
tion to persons requiring information? 

Is there a large amount of constant demand or emergency demand 
clerical work required in the function data streams? 

This means that clerical work must be differentiated from 
analytical work. Many clerical type jobs contain analytical 
tasks. These must be analyzed to ascertain if mechanization/ 
automation techniques can be applied. 

Is there a data or information requirement for many users in approximately 
the same time frame (users on same tactical unit or in different units) ? 

Can the cost of mechanization/automation be estimated? 

Can the cost of manual operations to be supported be estimated? 

Can the cost for supporting commanders be compared to costs for systems 
other than data handling (weapons, radar, etc., other service)? 
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Can function correspondence be established between competing systems? 

Can costs eventually be assigned to types of combatant ships and tactical 
organizations and missions? 

Can costs to interface with higher level or National Vertical Systems 
be stated (man power, money, time, etc.)? 
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4.0 DEVELOPMENT OF AN HARDWARE/SOFTWARE CONCEPT 

4.1 INTRODUCTION 

The ever increasing demand for data processing assistance to Naval functions 
in a tactical environment is evident. An important concern to Naval system planners is 
the proper evolution of such data systems in light of: 

Continual improvements in hardware capability 

Current investments and future commitments to hardware/ 
software 

Additional and/or continuing changing functional 
requirements 

Presented here is an approach to resolving these three apparently opposing 
forces. The rational.c.for this approach starts with the general purpose nature of digital 
computers and associated peripherals, which together with a suitably general purpose 
software framework will make it possible to develop ever increasing data processing 
services to multiple users in the form of a public utility. This system will be called the 
Integrated Naval Data Systems (INDS). 

This exposition is concerned with the problems of providing data processing 
services to Naval tactical units. These units are typically physical entities such as 
ships and airplanes. In particular, we are concerned here with the individual ship and 
will, for the most part, treat it as an entity, although it may be part of a Task Force or 
Group and hence have external dependencies. 

4.2 CURRENT APPROACH TO DATA PROCESSING SUPPORT 

The classical approach to analyzing the applicability or suitability of data 
processing to a particular problem Is to define the requirements, determine the processing 
load and recommend appropriate hardware and software solutions. This Indeed was the 
basic manner in which the Navy solved the specific problem of automatizing the CIC 
(e.g., NTDS). In fact, this has also been the approach in the design of the lOlC. 
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Hence, it is not surprising that today's CVAs include in their suit a variety of computer- 
ized subsystems including, for example: 

NTDS: USQ20 

lOIC: AN/UYKl, USQ20 

SPNIO: New digital system to replace analog computers 

Supply: UNIVAC 1500 (to be installed) 

It is evident at this time that such proliferation will probably continue on a 
subsystem basis. It must, however, be pointed out that the very fact that computers are 
general purpose is good enough reason why they should be looked upon as a centralized 
utility which can be made common to many purposes and, in fact, possibly on a more 
economical basis than decentralized and fragmented capabilities. 

Thus, just as the generation of electric power is an accepted centralized utility 
(at home, office or on ship), so data processing can be looked upon as a public utility. 
This concept is rapidly becoming a reality in today's commercial world as a result of 
significant technological advances with respect to developments in hardware and soft- 
ware in areas of data communication, time-sharing systems and remote user consoles. 
Hence, data processing as a public utility should be examined for relevancy to Naval 
tactical unit requirements. For conveniency we select the CVA as an example for this 
examination. 

4.3 OBSERVATIONS CONCERNING DATA PROCESSING ON A CVA 

Based on the considerations of the ANTACCS study to this date, and especially 
upon the one week trip on board the U.S.S. American (CVA), the following observations 
are made: 

a. The CVA is a large operational unit much like a large business. 
It has a variety of data processing problems, all of which are 
interrelated, hence requiring excellent communications. 

b. There are essentially three modes of ship operation: routine, 
flight operations and general quarters. 
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c. Often the same data is collected and passed on at more than 
one point on the ship. 

d. Often the same data is required by more than one point on 
the ship. 

e. Large volumes of redundancy in information are accumulated 
over short periods of time (e.g., CATCC). 

f . Much information is accumulated to identify exceptions or 
for demand review. 

g. The movement of data Is highly clumsy as it requires tote boards 
transcription. 

h. The reallabillty of hand written tote board Information is 
questionable. 

i. The flow of Information (reporting and dissemination) Is the most 
critical and "man consuming" task on board the CVA during 
General Quarters. 

j. There Is a simple but severe problem of capturing status infor- 
mation and relaying this information. 

k. The ship Is "talker" bound. 

I. Each ship subsystem has several alternatives for degraded service. 

m. There are a number of highly critical and time dependent 

operations where pressures on personnel are high and decision 
making significant (e.g., recovery of aircraft). 

Translating the above to data processing terms. It Is evident that the following 
technological capabilities can Improve performance: 

a. Remote data acquisition devices 

b. On-line data input devices 
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c. Data readouts displays 

d. Inquiry consoles 

Clearly these capabilities function best with on-line, remote user stations tied to a data 
processing system in the sense of what is popularly called a time sharing system. In 
addition to these peripheral devices which directly assist the personnel, it is also necessary 
to have the required data processing support. It is our strong conviction that the Navy 
investiage and consider a centralized and public utility for the following reasons: 

a. Provides common data base, limiting current redundancies 

b. Provides better system redundancies 

c. Simplifies overall EDP maintenance 

d. Reduces spare parts inventory 

e. Makes more efficient use of the equipment 

f. Possibly reduces total required equipment. 

These, of course, are the usual reasons for arguing for an integrated multi- 
computer system to serve as a public utility. In the case of the CVA there is the 
additional supporting requirement for centralization since most of the ship's operation is 
interrelated. Hence, if independent computerized subsystems were to prof ilerate (as 
they are now doing), there would come a time when a centralized computer system would 
probably need to be established anyway to perform the communication switching function. 

This combination then of public utility, time-sharing and centralized data 
processing forms the basis for the philosophy of the Integrated Naval Data System (INDS) 
presented here. 
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4.4 • RATIONALE FOR THE INTEGRATED NAVAL DATA SYSTEM 

The concept of the data processing public utility was first advanced by 
W. F. Bauer in a 1958 paper. It is known that several large corporations are now 
developing such systems for nationwide and public use. Dozens of other companies are 
developing such systems for their own use. In fact, the commerical market is possibly 
leading the military in this technological area. 

Perhaps at this point it is important to point out the difference between 
"centralized", "public utility", and "time-sharing" data processing systems. 

A public utility could be centralized or decentralized in the form of a single 
system or a network of systems. A centralized system could be a physically intact 
system of multiple modules or a distributed system. Time-sharing characterizes the 
method of using a data processing system. For example, multiple, on-line users of a 
public utility data processing system would not necessarily participate In time-sharing. 

We assume a computer utility for INDS having the following form and 
capability: 

a. Modular and expandable arithmetic and high-speed 
memory modules 

b. Communication multiplexers 

c. Auxiliary storages 

d. Conventional peripherals 

e. Special purpose, remoted and customer oriented peripherals. 

Such a system was described and motivated in the ANTACCS 1 Phase and in 
fact Is discussed in Volume III, page 5-32 of the Final Report. Also Informatics has 
advocated the development of a family of Naval computers to meet tactical requirements. 
This family has been discussed In Volume V of the ANTACCS Final Report and also In the 
special report submitted on the MTACC project, "MTAC Computer Technology Exploration", 
20 September 1965 and can serve as the basis for INDS. 
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In addition to the hardware, there is a requirement for an advanced 
Executive System which is capable of managing ever increasing demands on the 
system. This executive would perform all the traditional housekeeping tasks of a 
conventional monitor and the time-sharing function, and in addition would have the 
capability for dynamic scheduling, resource allocation and data management. 

The closest near state-of-the-art hardware and executive having the above 
attributes are those executives now being planned for systems such as the IBM 360-67 
and GE 645. Also the Air Force has such objectives as part of the GENESYS and 
INT IPS effort sponsored by ESD and RADC respectively. 

The Navy has the additional Important problem of developing a system 
rationale with does not: 

a. Invalidate current or programmed systems. 

b. Limit the load capacity on the system. 

c. Prohibit future improvements and/or displacement of 
specific hardware capability. 

d. Prevent fair competition to hardware manufacturers. 
An INDS like system can meet these objectives. 

Fortunately the Navy prescribed the now well known 30 bit NTDS communi- 
cation interface. 

INDS would carry forward this standard and thereby maintain an evolutionary 
Interface with current systems. When such systems are retired, they would be displaced 
by members of the family of Navy data processors. 

The load capacity would be open ended by virtue of the modularity of the 
computer family. 
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Future dependencies upon specific devices would be eliminated by providing 
users universal programming languages and symbolic data referencing or file management 
operators. 

Finally, the utilization of varied manufacturers devices v/ou Id not be limited 
as long as electronic interfaces are adhered to and the executive system is able to 
parametrize in a generic data processing sense the varied capability of the system 
components. 

Admittedly, much is assumed for the executive and penalties of overhead in 
efficiencies can be claimed for a system like INDS if it must meet the requirements of 
this section. 

Unfortunately cost effectiness studies for systems like INDS have not been 
adequately made at this time. Furthermore, most, if not all, of the current experience 
has been with fragmented time-sharing systems such as Project MAC or commercial 
systems such as IBM's Quiktran. (By this is meant that the A/\AC like systems service 
independent users.) Hence, it is not possible at this time to state conclusive arguments 
real ted to cost. 

However, it is equally important to consider INDS from a functional viewpoint 
and note the advantages that can be gained. This is done in the next section. 

4.5 . OPERATIONAL ASPECTS OF THE INTEGRATED NAVAL DATA SYSTEM 

As described in Section 4 INDS potentially meets desirable objectives from 
the point of view of hardware management and computer utilization. From the user's 
point of view INDS should ideajlyprovide a data processing service such that once pro- 
grams are designed and implemented modifications to the hardware system do not effect the 
user's operational programs. The analogy to an electrical power utility is the lack of concern 
by the consumer of how the electric power is generated, as long as a standard plug and 
no volts permits use of an electrical device. 
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Overall system functions would be relegated to the executive package. 
This leads to prescribing tight rules of hov/ job programs would tie into the system. 
Users would then prepare their jobs within well defined bounds, making easier the task 
of specific task implementation. 

This conclusion can not be supported at this time, since adequate experience 
is unavailable and appropriate studies have not been made. However, investigations by 
Informatics in the use of a higher order language (PL-1) for real-time operations concluded 
that dramatic savings in implementation efficiency are possible. The adequacy of 
sophisticated data management packages such as being developed now for the IBM 360 
family should be observed to determine the degree of savings such systems accrue to users 
end. 

Perhaps the best way to describe the impact of the recommendation being made 
here is to consider the effect of such a system on a potential subscriber. 

Subscribers fall into two classes: specific and general users. The first class 
expects to make careful, efficient and/or optimal use of the available utility resources. 

This group would require full understanding of the hardware and software and 
the detailed specification for specific devices. This group expects to gain advantages 
from specific system components, which under the philosophy of INDS raises a user risk 
since there would be no guarantee of future system integrity, both in terms of the 
continued presence of a specific device or the ability of supply specific services under 
degraded conditions. 

The second group of general users operate within the "universal" character 
of the INDS utility, both in terms of user oriented lanaguages that would be made avail- 
able and with respect to the problem of data and file management. These users would, 
for example, characterize information files in terms of logical records and associated 
symbolic references but never assign physical storage units or be concerned with physical 
addressing. 
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In addition to this type of usage, which is still very much data processing 
system and programming oriented, both \ha specific and general user would have avail- 
abel an additional INDS capability. This is the ability to make true user oriented 
requests of the system in terms of pre-programmed, task oriented operations. For 
example, there may be available query languages for file operation and file maintenance. 
Thus a user would not be expected to code his own programs to modify, delete or add 
a record to one of his personal files. Another user oriented INDS supplied capability 
would be a report generation capacity. Also there would be available arithmetic 
opei'ations and other functions which would be of common interest. 

Working within this higher order, task oriented capability, INDS would also 
permit combining available operations into newly ordered sequences of operations and 
thereby create new, and more sophisticated operations - without necessarily knowing how to 
to program a computer. 

Admittedly a general system such as is implied here must, for example, be 
parametrized so that users can express the nature of their problem and their expected 
usage so that the iNDS executive is capable of making best use in some optimizing 
sense of the specific hardware modules cuirently available to the system. In fact, 
"currently" in this regard refers to the moment of use. 

It is clear that a utility having a finite capacity and multiple consumers can 
not be designed to satisfy the absolute peak load. Since all users can be expected to 
request the fastest response possible it Is incumbent upon the INDS management to 
assign priority values to the contending users. Such a priority system is of course a dynamic 
one and would be expected to recognize, for example, that during the Recovery Cycle of 
Flight Operations the talking down of aircraft with the SPN-10 system becomes more 
important for a 30 second period that perhaps the update of a log which can be delayed. 

4.6 RECOMMENDATIONS FOR IMPLEMENTING INDS 

INDS is a concept for exploitation of computers. It Is a capacity which Is 
surely the direction of the near future. It is our belief that such a utility system will be 
common to military and commercial users. 
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Figure 7 compares the present approach to fulfilling system requirements to 
that of the hardware/software utility of INDS. The INDS development concept will 
permit specific requirements to be met by software addition rather than by hardware 
and software development. This approach requires one complete hardware and basic 
software system development cycle at the outset. This cycle may be five to seven years. 
Once the operational system is qualified and Implemented, specific requirements for 
processing are implemented by developing software only. This software cycle is one to 
two years and allows orderly system growth. System interface and integration decisions 
can now be made at the software levels ra'-her than at the hardware and software level. 

The concept of INDS has special significance to Naval tactical units and 
expecially for the CVA. Because of the long range commitments for outfitting ship 
units and incremental improvements made to existing ships it makes sense to remove the 
question of data processing compatibility, growth and operation from the end users to 
a specialized group of INDS managers. This group would have status equal to other 
service type departments responsible to the ship commander, e.g.. Supply Engineering. 
This department would be called the Data System Support Department. 

A decision to adopt a system like INDS would require the development of 
both a hardware and software capability. It is believed that the hardware concept 
could be developed in a year's time and a production of such hardware available some 
3 to 5 years later after the software implications are fully understood. 

The software question is more complicated. Here a true research project of 
some three years duration would be required. Such research would have to be performed 
by actual use of equipment. 

Hence the following is recommended: 

1 . Set up an INDS project office at some land based facility. 

2. Provide a reasonably good state-of-the-art time-sharing system 
having modular growth capability (e.g., PDP6, IBM 360-67, 
GE 645). 
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3. Include a 3 computer USQ 20 system consisting of a typical 
CVA set of programs to tie directly into the time sharing 
system . 

4. Prepare an Executive System reflecting the INDS capability. 

5. Demonstrate the utility by now implementing within the 
INDS Executive framework new capability. 

6. Produce specifications for hardware systems. 

Adequate performance of this test cell would then qualify the software concept 
for implementation within the framework of the recommended hardware. This combined 
hardware/software complex would then qualify as shown in Figure 8 . It is expected 
that an INDS like system could therefore be developed and fit for Naval operational 
use around 1975. 
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5.0 PLANS FOR THE COMPLETION OF ASSIGNED TASKS 

Figure 9 indicates the schedule for completing the present Phase II tasks. 
The scope definition and operating concept description will be completed in January 
1966. A tactical C&C system scope definition and a procedure for arriving at this 
definition is the first part of this product. An operation concept for the use of data 
systems in the second part of the product. The operating concept should be a descrip- 
tion of how the task commanders and tactical unit commanders might utilize data systems 
to support their command activities, operations, and functions. 

The hardware and software system concept task will be a detailed statement 
of the characteristics of the system . The subjects to be covered are the hardware and 
basic software characteristics and a blueprint for operational requirements, statements 
and software specifications. This work will be completed in May 1966. 

The CVA system description will contain a list of the operational tasks and 
technical functions to be supported and the application of the hardware/software family 
to meeting these support requirements. A plan for system evolution from present data 
systems will also be included. The work will be completed in May 1966. 
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